As is known in the art, computer systems which process and store large amounts of data typically include a one or more processors in communication with a shared data storage system in which the data is stored. The data storage system may include one or more storage devices, usually of a fairly robust nature and useful for storage spanning various temporal requirements, e.g. disk drives. The one or more processors perform their respective operations using the storage system. To minimize the chance of data loss, the computer systems also can include a backup storage system in communication with the primary processor and the data storage system. Often the connection between the one or more processors and the backup storage system is through a network in which case the processor is sometimes referred to as a “backup client.”
The backup storage system can include a backup storage device (such as tape storage or any other storage mechanism), together with a system for placing data into the storage device and recovering the data from that storage device. To perform a backup, the client copies data from the shared storage system across the network to the backup storage system. Thus, an actual data file may be communicated over the network to the backup storage device.
The shared storage system corresponds to the actual physical storage. For the client to write the backup data over the network to the backup storage system, the client first converts the backup data into file data i.e., the client retrieves the data from the physical storage system level, and converts the data into application level format (e.g. a file) through a logical volume manager level, a file system level and the application level. When the backup storage device receives the data file, the backup storage system can take the application level data file, and convert it to its appropriate file system level format for the backup storage system. The data can then be converted through the logical volume manager level and into physical storage.
Customers continue to struggle with providing the appropriate protection to their business applications. Backup is typically the name of the tool providing the protection, however, recovery and restore of applications may be the more important consideration. Backups may take very long times and provide points in time where the recovery can occur that are limited by the amount of time required for backup. Further steps are taken to complete the restore.
These processes may take hours or days before the customer is able to restore the application. Unfortunately in a modern global business climate with 24/7 internet commerce, recent studies indicate businesses cannot tolerate such long times for recovery. Instead there is almost no tolerance for application downtime. And there's another downside to doing the backups needed for restoration: Backup's can have a heavy impact on application servers, often the very ones needed to support the heart of the business applications. Moving large volumes of date at high speed for backup is CPU and I/O intensive.
Recovery requirements are becoming increasingly stringent. At one time a recovery window of 24 to 48 hours was considered reasonable for mission critical information, but this tolerance has shrunk to about an hour. Backups are expensive in terms of resources and congestion on application servers, creating a problem that only grows in complexity as the volume of information increases with geometric growth.
What is needed is a way to meet the demands of recovery described above without increasing requiring more backup operations and while not congesting traffic on application servers needed for business.